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ABSTRACT 

Pre-Requirement Specification traceability is the activity of 
capturing relations between requirements and their sources, 
in particular user needs. Requirements are formal technical 
specifications in the solution space; needs are natural lan- 
guage expressions codifying user expectations in the prob- 
lem space. Current traceability techniques are challenged by 
the complexity gap that results from the disparity between 
the spaces, and thereby, often neglect traceability to and 
from requirements. We identify the existence of an inter- 
mediary region — the transition space — which structures 
the progression from needs to requirements. More specifi- 
cally, our approach to developing change-tolerant systems, 
termed Capabilities Engineering, identifies highly cohesive, 
minimally coupled, optimized functional abstractions called 
Capabilities in the transition space. These Capabilities link 
the problem and solution spaces through directives (enti- 
ties derived from user needs). Directives connect the prob- 
lem and transition spaces; Capabilities link the transition 
and solution spaces. Furthermore, the process of Capabil- 
ities Engineering addresses specific traceability challenges. 
It supports the evolution of traces, provides semantic and 
structural information about dependencies, incorporates hu- 
man factors, generates traceability relations with negligible 
overhead, and thereby, fosters pre-Requirement Specifica- 
tion traceability. 
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1. INTRODUCTION 

Current traceability techniques falter when subjected to 
the dynamics of requirements evolution, user needs volatil- 
ity, market vagaries, technology advancements and other 
change-inducing factors that plague software systems dur- 
ing their development cycles. Undoubtedly, the inability to 
precisely capture and represent the effect(s) of each change 
has contributed to the long history of system failures [7]. 
Although, the importance of traceability, and in particu- 
lar requirements traceability (RT), was recognized in the 
early nineties [10], the research community is still grappling 
with the challenges of traceability, especially between re- 
quirements and their source needs. In large part, this is 
because of the difficulty in formalizing user needs, which are 
often unstructured information. Although, needs are infor- 
mal expectations of users, they serve as the primary source 
for requirements specification. If a software system is to 
exhibit the "right" functionality, then it is imperative that 
each system requirement satisfies one or more user needs. 

Because system validation is performed against require- 
ments, it is critical that we have the ability to trace require- 
ments back to their source needs. This type of traceability 
is known as pre-Requirement Specification (pre-RS) tracing 
[10] . In fact, it is empirically established that inadequate 
pre-RS tracing is far more responsible than than post-RS 
tracing (tracing requirements to design/code artifacts) for 
defective RT [6] [18]. We conjecture that this is because 
post-RS tracing works within the convenience of the solu- 
tion space, mapping requirements to design or code entities. 

However, pre-RS tracing is required to trace entities from 
the problem space (needs) to the solution space (require- 
ments). The chasm between these spaces, i.e. the complex- 
ity gap [23], is too large of a leap for current traceability 
techniques. In addition, the effects of this gap — manifested 
as loss of domain information, misinterpreted requirements, 
misconstrued needs — are exacerbated during the develop- 
ment of large-scale systems. We term the intermediary re- 
gion that includes the complexity gap as the transition space 
and use it to ease the giant leap from needs to requirements. 
Figure [T] illustrates the difference between the traditional re- 
quirements engineering approach and our solution approach 
in advancing from the problem to the solution space. 

Our solution approach for pre-RS traceability is derived 
from Capabilities Engineering (CE), a process for architect- 
ing change-tolerant systems by constructing functional ab- 
stractions termed Capabilities in the transition space [26] . 
These abstractions exhibit high cohesion and low coupling. 
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Figure 1: Transition from Needs to Requirements 



The characteristic of high cohesion localizes the impact of 
a change. Low coupling implies reduced dependencies, and 
thereby, minimizes the ripple effect of change. Ripple ef- 
fect is the phenomenon of propagation of change from the 
affected source to its dependent constituents [12]. Capa- 
bilities influence the basic composition of systems, and in 
some sense, impose a high-level architecture. Capabilities 
are formulated from user needs and mapped to system re- 
quirements. In the process, they occupy a position that 
is neither in the problem space nor in the solution space. 
More specifically, although Capabilities are derived from 
user needs, they are imbued with design characteristics of 
cohesion and coupling. This introduces aspects of a solu- 
tion formulation, and thus, discourages the membership of 
a Capability in the problem space. On the other hand, Ca- 
pabilities are less detailed than entities that belong to the 
solution space. Consequently, Capabilities fit more natu- 
rally in the transition space. Furthermore, their formula- 
tion from the user needs and mapping to requirements imply 
that they have the potential to bridge the complexity gap; 
thus assisting the traceability between needs and require- 
ments as depicted in Figure Q] Moreover, the inherent abil- 
ity of Capabilities-based systems to accommodate change 
with minimum impact enhances the efficacy of traceability; 
random, unstructured ripple-effect impairs the strength of 
regular traceability techniques. 

The Capabilities-based development approach strives to 
accommodate change with minimum impact, and therefore, 
incorporates pre-RS tracing in its process; traceability is the 
cornerstone of change- management. The use of the tran- 
sition space facilitates the capture of domain information, 
and preserves relationships among needs and their associ- 
ated functionalities during the progression between spaces. 
On the other hand, the characteristics of high cohesion and 
low coupling of Capabilities, support traceability in evolving 
systems by localizing and minimizing the impact of change. 
The ability to trace is unhindered by the system magnitude 
when utilizing a Capabilities-based development approach 
because traceability techniques are embedded into the pro- 
cess. Moreover, by considering traceability as an integral 
part of the development effort, several issues relating to hu- 
man factors can be resolved. For example, often the impor- 
tance of traceability is undermined because it is regarded as 
a time-consuming activity when executed in isolation. 

The remainder of the paper is organized as follows: Sec- 



tion [2] discusses related work and outlines the overall pro- 
cess of engineering Capabilities. In Section [3] we define 
each space, discuss the role of CE in facilitating traceability 
within each space and examine the spaces' connectivity in 
terms of common linkages. Then, in Section [4] we present 
how the use of a Capabilities-based development approach 
addresses specific challenges of traceability. Our conclusions 
are surmised in Section [5] 

2. BACKGROUND 

We first clarify the usage of the terms "requirement" and 
"requirement specification" in the context of our research. 
A common definition of RT is the "ability to describe and 
follow the life of a requirement, in both a forwards and back- 
wards direction" |10] , Forward traceability is tracing a re- 
quirement to its design or code entities, and backward trace- 
ability is tracing a requirement to its sources [32] . According 
to these definitions a requirement is not necessarily a part 
of a specification document. Pre-RS tracing, however, refers 
to the traceability aspects of a requirement before its inclu- 
sion in a specification document. Consequently, there is an 
overlap between the different modes of traceability; this is 
graphically illustrated in [20]. This overlap stems from the 
fact that a requirement is iteratively refined until it is suit- 
able for a formal specification. As a result, any statement 
that describes what is expected from the system, irrespective 
of its level of refinement, is termed a requirement. However, 
we make a distinction with respect to the terminology used. 
We consider a requirement as a statement that is formally 
recorded in a software requirements specification document 
[19] . Therefore, we consider the terms requirement and re- 
quirement specification as one and the same, and so use 
them interchangeably. 

Several models have been constructed to assist pre-RS 
traceability. For example, Contribution Structures [11] con- 
sider the role of users, personnel, and others, in eliciting 
information to trace the origin of requirements. Similarly, 
Yu and Mylopoulos [34] factor in the influence of the re- 
lationships between stakeholders on the RT process. These 
methods emphasize the social aspect of requirements elicita- 
tion. On the other hand, Pohl 121 tailors the Requirements 
Engineering (RE) environment to capture traceability infor- 
mation between needs and requirements using PRO-ART. 
More general reference models for traceability have been de- 
veloped by Ramesh and Jarke ^25^ . In the Capabilities-based 
development approach, traceability information is more of 
an implicit by-product. 

Empirical research evidence indicates the failure of tra- 
ditional RE to cope with requirements evolution, especially 
when building large systems [3]. In contrast to traditional 
RE which attempts to minimize change, CE strives to ac- 
commodate change with minimum impact. The difference 
in the change-management strategies explains why the ac- 
tivity of traceability is an inherent part of the CE approach, 
whereas it is considered an extraneous activity in the RE 
approach. Although, CE utilizes stable Capabilities to de- 
velop the system, it is imperative that the process also has 
the ability to trace to and from the changed entities inorder 
to ensure the successful accommodation of change. 

Figure [2] illustrates the major steps of the CE process. 
Capabilities are identified after needs analysis but prior to 
requirements specification, and indicate the functionality 
desired of a system at various levels of abstraction. As 
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Figure 2: Capabilities Engineering Process 



shown in Figure [2] Capabilities are formulated from direc- 
tives. Directives are system characteristics obtained from 
user needs. They assist in the transfer of domain infor- 
mation, and help determine the initial sets of Capabilities, 
based on the values of cohesion, coupling, and abstraction 
level [27]. These sets are then subjected to the constraints 
of technology and schedule to produce an optimized set of 
Capabilities. Throughout the process, Capabilities are asso- 
ciated with a set of directives, which are finally transformed 
to requirements. The output of the CE process is a set 
of finalized Capabilities, and their associated requirements. 
Hence, needs transition to requirements through directives 
and Capabilities. 

In the following section we discuss how the relationship 
between needs, directives, Capabilities and requirements, as 
defined by the CE process, aids in pre-RS traceability and 
conceptually prove that Capabilities help bridge the com- 
plexity gap. 

3. ROLE OF CE IN PRE-RS TRACING 

Traditional RE transitions directly from needs to require- 
ments, as illustrated in Figure [1] Needs are the primary 
source of information for system development. They are 
stated in a natural language form, and thereby, can often be 
ambiguous, vague and misleading. Hence, needs are unsuit- 
able as input to the design phase; instead, we utilize system 
requirements derived from user needs. Thus, there is a tran- 
sition from needs to requirements. These requirements are 
more formal, and display quality characteristics such as ac- 
curacy, unambiguity, testability, and others pQ. Although, 
formalization of requirements does reduce the possibility of 
misinterpretations, it usually fails to convey pertinent prob- 
lem domain information. In fact, it has been recognized 
that the informality of a natural language has the advan- 
tage of communicating certain knowledge that formalization 
neglects to capture [S]. This loss of information has been 
identified as a key issue in RE |35| . 

We claim that there exists an intermediary space, which 
symbolizes a middle-ground between the the extremes of 
formality and informality. This space provides an opportu- 
nity to metamorphose from the natural informality of the 
problem space to the rigid formality of the solution space 
in a more deliberate and systematic manner. In addition, 
the consequences of a direct leap from the problem domain 
to the solution domain — misinterpreting needs, missing 
requirements, loss of domain information and so forth — 
can be mitigated. We term the intermediary space that in- 
cludes the complexity gap as the transition space. Again, 
Figure [T] graphically illustrates how CE uses the transition 
space to decrease the leap from problem to solution space. 
In other words, Capabilities assist in a smoother transition 



from needs to requirements. 

Sections 13.11 13.21 and 13.31 discuss in detail the problem, 
transition and solution spaces, respectively. In particular, 
we first define and describe the elements of each space, then 
discuss what activity of the CE process is executed, and fi- 
nally explain how traceability is achieved within that space. 
Lastly, in Section r3.4l we present a unified perspective on the 
connectivity between the three spaces, and illustrate how 
pre-RS traceability is automatically supported by the activ- 
ities of the CE process. 

3.1 The Problem Space 

The distinction between a space and a domain is often 
blurry and is used interchangeably. For example, the term 
problem space is used to indicate a conceptual region of 
relevance associated with the problem area [31] [30]. How- 
ever, in some instances the term problem domain is also 
employed to imply the same [15] |28j . For the purposes of 
clarity, we utilize the notion of problem and solution do- 
mains as discussed by Hull et al. to describe spaces [13] . 
More specifically, we characterize a space in terms of three 
elements: the view, the domain and the resident entities. 
By this characterization, the problem space is composed of 
the entities: needs and directives. These entities are defined 
from a user's view and are described in the language of the 
problem domain. Formally, the problem space is a collec- 
tive aggregation of user view, problem domain, needs, and 
directives. Activities such as problem identification, decom- 
position, domain analysis [32] and others that help impart a 
better understanding of the problem, are performed in this 
space. An application of the user view on the problem do- 
main generates needs, which are, to a large extent, informal 
and unstructured. A pictorial representation of the problem 
space is shown in Figure [3] 
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Figure 3: Problem Space 

User View: This refers to the perspective of a stake- 
holder who is interested in the system to be developed. 
The user view includes both direct and indirect view- 
points 16_. 

Problem Domain: The problem domain denotes the 
knowledge area(s) relevant to the problem being solved. 
For example, if the problem is to build an ATM, then 
the problem domain is banking. 

Needs: A need specifies what is desired of the system 
from a user's perspective, and is stated in the language 
of the problem domain. It is obtained by the applying 
a user view on the problem domain. It is composed 
of objects and operations of the problem domain as 



perceived by the user. Resulting needs cause the gen- 
eration of other needs. User views can also activate 
other user views. Hence, every element feeds into the 
problem space as an input to produce more needs. 

• Directives: We define a directive as a detailed charac- 
teristic of the system formulated in the problem do- 
main language. It can be regarded as a requirement 
with context information. In the problem space, the 
purpose of a directive is two- fold. First, it helps cap- 
ture domain information. Second, it facilitates the 
progress from the problem space to the transition space. 

An example of a user need, a directive, a Capability and a 
requirement, for a hypothetical course management system 
is described in Table [T] 



Entity 


Example 


Need 


Need a facility for students and faculty 
to share ideas, discuss questions 


Capability 


Discussion Forum 


Directive 


Provide a separate section for faculty to 
post important announcements 


A Requirement 


For the announcement section, the write 
permission must be enabled only for 
users designated as faculty. 



Table 1: Examples in the context of a Course Man- 
agement System 



We begin the process of CE by discovering, eliciting and 
understanding needs from the user. The "needs" component 
of the CE process, and the subsequent decomposition to di- 
rectives illustrated in Figure [2] is confined to the problem 
space. In the following section, we explain the decompo- 
sition activity, expand on the role of directives and then 
discuss how the deliverable of the decomposition activity — 
a Function Decomposition (FD) graph — aids traceability. 

3.1.1 CE Activity 

• Decomposition: Decomposition is an intuitive process 
of recursively partitioning a problem until an atomic 
level is reached. This activity uses an FD graph to 
represent a decomposition of system functionality, as 
indicated by user needs at various levels of abstraction. 
We begin with user needs because they help determine 
what problem is to be solved; in the context of software 
engineering this means what functionality is expected 
of the system to be developed. Different techniques 
such as interviews, questionnaires, focus groups, in- 
trospection and others [9] are employed to gather in- 
formation from users. A need can be expressed as a 
real want or a perceived solution. In either case, we 
are interested only in understanding the functionality 
expected of the system. Often, because of the infor- 
mality of the problem domain language, needs are ex- 
pressed at varying levels of abstraction; the variance 
in abstraction is depicted by the depth of a node in 
the FD graph, where depth is the distance of a node 
from the root. Thus, greater the distance, lower is 
the abstraction level. The links (edges) between the 
nodes indicate decomposition, intersection or refine- 
ment relationships. The FD graph provides a visual 



representation of the system functionality, depicting 
the dependency links between different functions. The 
use of such a graph supports comprehensive pre-RT 
traceability as discussed in Section [37L2] 
An FD graph, G = (V, E), is an acyclic directed graph, 
where V is the vertex set and E, the edge set. Figure 
[4] presents an example graph. The root node repre- 
sents the overall mission of the system, internal nodes 
denote functional abstractions and the leaves symbol- 
ize directives. In fact, it has been observed that in 
a decomposition tree, detailed information is usually 
specified at the leaves [31]. Similarly, directives are 
low-level details pertaining to the system to be devel- 
oped. An edge can represent decomposition, intersec- 
tion or refinement of a functionality, as depicted in 
Figure [4] Decomposition implies that the functional- 
ity of a parent node is equivalent to the union of the 
functionalities of its children nodes. An intersection 
edge indicates a common functionality. Refinement is 
used to elaborate the functionality of the parent node. 
For a more formal exploration of the FD graph see [26] . 
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Figure 4: Example FD Graph G = (V, E) 

3.1.2 Traceability in the Problem Space 

We now enumerate how the FD graph, resulting from the 
activity of decomposition, assists in pre-RS traceability: 

1. By the virtue of construction, the FD graph represents, 
in some sense, dependency links between user needs. 
A change in a parent node affects one or more of its 
children. Therefore, the effect of a change in a need is 
more easily traced to its dependent constituents. Sub- 
sequently, the FD graph facilitates traceability among 
needs. In contrast, present traceability methods are 
more concerned with the traces between requirements 
and its sources, rather than links within the sources 
themselves. As a result, a changed need is traced 
only to its associated set of requirements; there is in- 
sufficient information to assess the impact of change 
on other needs, and subsequently, their requirements. 
Thus, we claim that this type of traceability is impor- 
tant to understand the ripplc-cffect of change within 
needs, so as to completely record the effect on require- 
ments. When utilizing the FD graph, explicit efforts 
to maintain traces among the source needs are unnec- 
essary. 

2. The FD graph presents an intuitive decomposition of 
functionality expected of the system to be developed. 



In the process of decomposition, as shown in Figure 
[H nodes are described at different levels of abstrac- 
tion. This kind of a visual representation encourages 
the user to focus on the functionality of the system, 
rather than on the low-level details. In addition, the 
hierarchical decomposition of the needs' functionality 
permits a more systematic approach to stating what 
is expected of the system. This reduces the possibil- 
ity of representing conflicting statements, redundant 
functions, and inconsistent expectations across differ- 
ent user classes. Furthermore, the FD graph, struc- 
tures the informality of problem space, and thereby, 
provides an opportunity to automate the traceability 
process. 

3. The leaves of the FD graph are directives, which are 
described in the language of the problem domain. The 
set of all directives represents the entire system func- 
tionality. Figure [2] indicates that directives are used 
to formulate Capabilities that occur in the transition 
space. More specifically, directives are the connect- 
ing links between the problem and transition spaces, 
and thereby, help preserve and transfer the problem 
domain information from the former to the latter. We 
claim that directives implicitly aid pre-RS traceability, 
by serving as inter-connections between the disparate 
spaces. Section \3 . 2 1 elaborates on this aspect. 

It is inevitable that a large part of the needs elicited from 
different sources is inconsistent or conflicting |14|. However, 
the use of an FD graph helps capture needs and represent 
desired system functionalities in a systematic manner. Fur- 
thermore, the graph also represents functions at different 
levels of abstraction, which aids in understanding their rel- 
ative importance. For example, fulfilling the overall mis- 
sion of the system is more important than implementing a 
directive. The structure of the graph facilitates traceabil- 
ity among needs by introducing aspects of formality in the 
highly irregular problem space. 

Recall that the leaves of the graph are directives, which 
connect the problem and the transition spaces. In the fol- 
lowing section, we describe how Capabilities, defined in the 
transition space, are formulated from these directives, and 
subsequently, discuss traceability within and between Capa- 
bilities. 

3.2 The Transition Space 

In the transition space, we introduce specific design char- 
acteristics of cohesion and coupling. We know that entities 
with these properties localize and minimize the propagation 
of change, which is crucial for promoting change-tolerance 
and also for structuring pre-RS traceability. We move away 
from the informality of the problem space by adopting a sys- 
tem view — introducing design aspects of cohesion and cou- 
pling — on the expected functionality of the system. How- 
ever, we still utilize the problem domain but generate new 
entities termed Capabilities. Thus formally, the transition 
space is defined as a collective aggregation of system view, 
problem domain, and Capabilities. A pictorial representa- 
tion of the transition space is shown in Figure [5] Note that 
directives are also present in the transition space because 
they facilitate the change from the problem to the transi- 
tion space. They originate, however, in the problem space, 
and so belong there. 



Transition Space 




Figure 5: Transition Space 

• System View: We define system view as the software 
engineering perspective that guides the identification 
of Capabilities based on the design principles of high 
cohesion, low coupling, balanced abstraction levels, as 
constrained by schedule and technology. Figure [5] il- 
lustrates that initial Capabilities are formulated from 
directives. These initial Capabilities are iteratively op- 
timized to produce an optimized set of Capabilities. In 
essence, formulation and optimization, the activities of 
the CE process as shown in Figure [2] incorporate the 
system view to produce Capabilities. 

• Capabilities: We describe Capabilities as functional 
abstractions that exhibit high cohesion, low coupling 
and are defined at balanced levels of abstraction [27] . 
The optimized set of Capabilities, chosen to develop 
the system, reflect the constraints of technology feasi- 
bility and implementation schedules. 

The input to the transition space is an FD graph, which 
describes expected system functionalities at varying levels of 
abstraction, and directives that help realize these functions. 
The activity of formulation, uses these directives to identify 
initial sets of highly cohesive, minimally coupled Capabili- 
ties. Then, the optimization activity applies the constraints 
of schedule and technology to determine the final set of Ca- 
pabilities. We briefly describe each of these activities and 
then discuss how they assist in pre-RS traceability. 

3.2.1 CE Activity 

• Formulation: The objective of the formulation activ- 
ity, as shown in Figure [5] is to identify sets of Capabil- 
ities from all possible functional abstractions, depicted 
in the FD graph. For example, for the graph described 
in Figure [4] the set of nodes {ni, 717,713} is a poten- 
tial set of Capabilities because it encompasses all di- 
rectives. Furthermore, each node is associated with a 
unique set of directives; directives {d\, . . . ,d$} are as- 
sociated with m, {da, . . ■ , dg} with n-j, and {dio, ■ • ■ , 
du\ with 713. Many different sets can be computed 
from a single FD graph. By applying specific measures 
|26| we choose those sets which exhibit high cohesion 
and low coupling values. A discussion about the de- 
tails of these metrics is outside the scope of this paper. 
Instead, for the purpose of understanding traceability 
aspects, we direct our attention to the cohesion and 
coupling characteristics of Capabilities. 



Cohesion, depicts the "togetherness" of elements within 
an entity. Every element of a highly cohesive unit is 
directed toward achieving a single objective. Capa- 
bilities are designed to possess high functional cohe- 
sion, the highest level of cohesion [J among all the 
other levels [33], and therefore the most desirable. In 
a Capability all of its associated directives are devoted 
to realizing the function represented by the Capabil- 
ity. Failure to implement a directive can affect the 
functionality of the associated Capability with vary- 
ing degrees of impact. We hypothesize that the degree 
of impact is directly proportional to the relevance of 
the directive to the functionality. Consequently, the 
greater the impact, the more essential the directive. 
Hence, each directive is assigned a weight on a [0, 1] 
scale to indicate its relevance value; existing risk im- 
pact categories: Catastrophic, Critical, Marginal and 
Negligible [5] are used to guide this assignment [26] . 

The other characteristic of Capabilities is low coupling. 
Coupling is a measure of interdependence between en- 
tities |29j . Dependency links between entities behave 
as change propagation paths. The higher the number 
of links, the greater is the likelihood of ripple effect. 
The edges of the FD graph indicate the links between 
Capabilities and their directives. We measure coupling 
between Capabilities as a function of the coupling be- 
tween their constituent directives [26] . 

• Optimization: The inputs for the optimization activity 
are sets of highly cohesive, minimally coupled Capabil- 
ities. This activity aims to identify that set which best 
accommodates the constraints of schedule and tech- 
nology, and is an ongoing component of our current 
research. 

3.2.2 Traceability in the Transition Space 

We now discuss how the structure and characteristics of 
a Capability and its associated directives assist in pre-RS 
traceability in the transition space. 

1. Capabilities are functional abstractions identified from 
the FD graph, and are associated with a set of direc- 
tives. Capabilities provide stakeholders with a high- 
level perspective of the system functionality. In con- 
trast, directives within each Capability furnish the more 
rudimentary details. We claim that the structure of 
Capabilities and their directives serve the pre-RS trace- 
ability interests of two disparate groups of users - 
high-end and low-end users — as identified by Ramesh 
[24] , High-end users work with complex systems that 
have a large number of requirements, and can easily 
become entangled in the details. However, Capabili- 
ties can be utilized to understand, from a high-level 
perspective, the expected system functionalities, and 
thereby, ensure that user expectations are satisfied. In 
contrast, low-end users are known to neglect pre-RS 
traceability because they are more concerned with de- 
tailed requirements. In such a case, these users can fo- 
cus on directives to trace the origin of requirements be- 
cause they are similar to detailed requirements but are 
stated in the language of the problem domain. Thus, 
we claim that Capabilities and their directives help 
overcome certain shortcomings of pre-RS traceability 
among different groups of users. 



2. Capabilities exhibit high functional cohesion. Each as- 
sociated directive, with varying degrees of relevance, is 
essential for realizing a Capability. A change in a di- 
rective may affect the parent Capability, and also other 
associated directives. Thus, Capability-directive links 
established by the FD graph can be utilized for the 
purposes of traceability. In other words, the property 
of high cohesion facilitates traceability within a Capa- 
bility. 

3. Minimally coupled Capabilities reduce the overhead 
of maintaining traceability information between each 
and every directive. This is because low coupling im- 
plies decreased dependencies, and therefore, reduces 
the need for traceability paths between certain enti- 
ties. 

4. One can use information from the FD graph to record 
which directives are common to different Capabilities, 
and maintain traces for them. This is in agreement 
with the observation that a change in a detailed re- 
quirement is often less significant, and hence, it is more 
cost efficient to maintain traceability for critical enti- 
ties [53]. The criticality of directives can be deduced 
from their relevance values, which are elicited for the 
computation of the cohesion measure. 

In the transition space, we use the system view to formu- 
late and optimize Capabilities from the FD graph generated 
in the problem space. We observe that directives behave 
as linkages between the two spaces, and also, preserve and 
transfer problem domain knowledge. These directives are 
transformed to requirements, which belong to the solution 
space. We now discuss the solution space, the CE activity of 
transformation (shown in Figure [2} and traceability within 
the space. 

3.3 The Solution Space 

The solution space is usually understood as the concep- 
tual realm associated with the technical aspects of devel- 
oping the system. Often, as with the problem space, the 
terms solution domain and space are used interchangeably. 
However, we envision the solution space as being defined 
by the system view, which generates entities called require- 
ments from directives. These requirements are described in 
the language of the solution domain. We formally describe 
the solution space as the collective aggregation of the system 
view, the solution domain, and requirements. In the solu- 
tion space, activities related to developing the system, such 
as establishing requirements, modeling architecture, devel- 
oping design specifications, coding, unit testing, integration 
and testing, system maintenance and other downstream de- 
velopment processes are performed. We restrict our focus 
up to the specification of requirements, and therefore, the 
graphical representation of the solution space in Figure [6] 
presents only Capabilities and requirements as its entities. 
Capabilities that are present in the solution space, are the 
unchanged entities that originated in the transition space. 
Hence, Capabilities behave as connectors between the tran- 
sition and solution spaces, just as directives do between the 
problem and transition spaces. 

The element, system view, has already been defined in 
Section [3.21 Therefore, we now describe the other elements 
— solution domain and requirements — of the solution space. 
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Figure 6: Solution Space 



• Solution Domain: Solution domain denotes the tech- 
nical area(s) relevant to the system being developed. 
This assumes that a solution always implies the de- 
velopment of a system, which is true in software en- 
gineering. For example the solution domain provides 
technical concepts such as design patterns and archi- 
tectural styles that are relevant to the design of an 
ATM. 

• Requirements: A requirement is a statement specified 
in the language of the solution domain that states what 
is expected of the system and exhibits specific quality 
characteristics such as testability, verifiability, accu- 
racy, unambiguity, and others pQ. 

The input to the solution space is an optimized set of 
Capabilities and their associated directives. Moving from 
the transition to the solution space entails a change in the 
domain language used to describe the entities. In partic- 
ular, requirements are now stated in the solution domain 
language. These requirements are derived from directives. 
Recall, directives originate in the problem space, assist the 
change to the transition space and are now transformed to 
requirements in the solution space. Also, Capabilities iden- 
tified in the transition space progress unchanged into the 
solution space, and in the process become associated with a 
set of requirements as opposed to a set of directives. We now 
examine the transformation activity and discuss traceability 
in the solution space. 

3.3.1 CE Activity 

• Transformation: Requirements are still the basis for 
developing systems. They fulfill several purposes that 
include providing the rationale for design, criteria for 
validation and others as enumerated in [10] . Thus, 
there is a need to transform directives to requirements. 
In systems that are incrementally developed, only the 
directives associated with the Capability chosen for de- 
velopment are to be transformed to requirements. This 
is in agreement with the principle of delaying the spec- 
ification of requirements in Capability Based Acquisi- 
tion |17j , and thereby, avoiding the pitfalls of fixed re- 
quirements. We hypothesize that there is a one-many 
mapping between directives and requirements. 

3.3.2 Traceability in the Solution Space 
Traceability aspects of the transition space are applicable 

to the solution space because of the similarity between direc- 
tives and requirements. Both are low-level detailed entities 



that describe what is expected of the system. We enumerate 
the traceability advantages in the solution space obtained by 
the utilization of the CE process. 

1. When transforming directives to requirements, one can 
use the relevance values to determine the criticality 
of requirements. Recall that relevance values indicate 
the importance of a directive in achieving the objec- 
tive of its parent node. For example, a directive with a 
relevance value 1 is mission-critical, and therefore, re- 
quirements derived from this directive are most likely 
critical too. This information can be utilized to selec- 
tively capture certain traces. In fact, it has been rec- 
ognized that not all requirements are equal and that it 
is cost-effective to maintain traces to and from critical 
requirements [24] . 

2. Pinheiro [20] describes inter-requirements traceability 
as capturing the relationships between requirements. 
The CE process assists this type of traceability in three 
different ways: 

(a) A directive is transformed into one or more re- 
quirements. Because the requirements are de- 
rived from the same directive, they share a very 
strong relationship, and therefore, a change in one 
is most likely to affect the other requirements. 
Hence, there is an implicit inter-requirements trace- 
ability among requirements derived from the same 
directive source. 

(b) In the solution space, Capabilities are associated 
with a set of requirements that are transformed 
from directives. Note that Capabilities are un- 
changed when progressing from the transition to 
the solution space. By definition, Capabilities ex- 
hibit high functional cohesion; every element is 
essential to attaining its objective. Therefore, re- 
quirements associated with each Capability are 
strongly related to each other because each re- 
quirement is working towards fulfilling the same 
Capability. This facilitates inter-requirements trace- 
ability within a Capability and alleviates the over- 
head of analyzing exponential number of relation- 
ships among all possible requirements. 

(c) Minimally coupled Capabilities aid in selective 
traceability between the requirements associated 
with different Capabilities. Directives that are 
shared among Capabilities in the transition space 
result in requirements which are common in the 
solution space. As a result, traceability efforts 
can focus on these requirements, which have the 
potential to affect more than one Capability when 
changed. 

3. Tracing is performed only when a need is perceived. 
For example, requirements are tagged with keywords, 
cross-referenced, etc., to facilitate future tracing. How- 
ever, the same importance has not been extended to 
the tracing from needs to requirements. We conjec- 
ture from the observations above that the process of 
CE may ease the difficulty of tracing from needs to 
requirements and thereby, further assist pre-RS trace- 
ability. 



Thus, in the solution space, requirements are specified 
for Capabilities that are to be developed. These require- 
ments are obtained from directives by the activity of trans- 
formation. The nature of a Capability, and its directives or 
requirements, facilitate traceability in the transition space 
and the solution space, respectively. Moreover, the proper- 
ties of Capabilities assist in inter-requirements traceability. 
We now briefly discuss, from a more global perspective, how 
the different spaces are connected. 

3.4 Connecting Spaces 

The preceding sections have described and discussed the 
traceability aspects in each space. In this section, we adopt 
a unified perspective and examine the relationship between 
the spaces. This is essential to understand the potential 
for traceability from needs to requirements using the CE 
process. When making a transition from one space to an- 
other, either the domain or the view varies. For example, 
the view changes in the progression from the problem space 
to the transition space; the domain changes in the shift from 
transition space to the solution space. This is presented in 
Table [2] where the italicized entries indicate the changed 
element. In addition, we observe that the spaces are con- 
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Table 2: Connecting the Spaces 



nected through common entities. Needs are decomposed to 
directives in the problem space; these directives are utilized 
to identify Capabilities in the transition space. As men- 
tioned earlier, directives carry with them problem domain 
information which is preserved in the transition space. Fur- 
thermore, they are also used to identify Capabilities, which 
pass unchanged into the solution space. Thus, Capabilities 
and directives behave as connectors between the problem 
and solution spaces. Figure [7J graphically illustrates the 
transitions between and common elements resident in the 
spaces. The solution approach of the CE process illustrated 
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Figure 7: Capabilities Engineering in terms of Spaces 

in Figure [Jj strives to resolve the problem of the complexity 
gap represented in Figure [JJ This is achieved by introducing 



Capabilities to bridge the chasm between the spaces. In ad- 
dition, the conventional overhead and difficulties associated 
with pre-RS traceability are alleviated with the utilization 
of the CE process. 

4. TRACEABILITY CHALLENGES 

In this section we examine from a pre-RS traceability per- 
spective how CE addresses specific challenges. In particular, 
we refer to the challenges enumerated in the Grand Chal- 
lenges document [2] to structure our discussion. 

4.1 Supporting Evolution 

Large-scale systems constantly evolve during their lengthy 
development cycles. Consequently, there is an enormous 
overhead in ensuring that the traceability links depict cur- 
rent dependencies. Changes can occur in needs, directives, 
Capabilities or requirements. However, we are specifically 
concerned with the impact of any such change on Capabil- 
ities or requirements because they are the formal inputs to 
the development phases. Therefore, we present how CE fa- 
cilitates traceability to requirements in the event of different 
change scenarios. 

• Needs Change: The FD graph illustrates a decomposi- 
tion of functions, which essentially represents the user 
needs. The visual structure of the graph provides in- 
formation about nodes that can be affected by a need 
change. For example, in Figure [4] if a need associated 
with node n$ changes, then it is evident that nodes ns 
and ng are most likely to be affected because they are 
connected by decomposition edges to the parent node 
nz. If any of the affected nodes are Capabilities, then 
the set of associated requirements are also impacted. 

• Directives Change: In the event of a directive change, 
its relevance value can provide an estimate of the pos- 
sible impact on the associated Capability. Further- 
more, this change also affects those requirement (s) ob- 
tained from the changed directive. Also, coupling be- 
tween Capabilities is computed as a function of the 
coupling between their respective directives. There- 
fore, low coupling implies that a change in a directive 
has a decreased likelihood of affecting directives in an- 
other Capability, or their derived requirements. 

• Capabilities Change: The high cohesion and low cou- 
pling of a Capability contains the impact of change 
to within a Capability. In all likelihood, only the set 
of requirements associated with it are affected. The 
dependencies between Capabilities can be examined 
using the FD graph to analyze the paths of change 
propagation. 

• Requirements Change: As with directives, requirement 
changes are contained to within a Capability. Reduced 
coupling between Capabilities ensures that a change in 
a requirement has low impact on requirements associ- 
ated with other Capabilities. 

Thus, no special effort is required to maintain the trace- 
ability information about all links in the pre-RS phase. In- 
stead, the design of the FD graph and the subsequent deriva- 
tions of requirements from directives, provide a natural means 
for traceability. In addition, a Capability's characteristics of 



high cohesion and low coupling, contain and reduce the im- 
pact of change, respectively. This serves to alleviate the 
burden of capturing all possible traces, which is otherwise 
difficult in an evolving system. 

4.2 Link Semantics 

The FD graph is constructed in the problem space in ac- 
cordance to certain rules. In particular, different types of 
nodes and edges are interpreted in the context of the prob- 
lem space. As a result, by the virtue of its definition, the FD 
graph provides both link semantics and indicates the granu- 
larity of nodes. This information is essential to understand 
the underlying traceability relationships. 

• Link Type: The FD graph is currently concerned only 
with representing expected system functionality, and 
not with the depiction of non-functional needs. There- 
fore, we define the edges of the graph to represent de- 
composition, intersection or refinement relationships. 
These links are independent of any particular domain, 
and therefore, are fundamental in nature. 

• Granularity: The root of the graph represents the over- 
all system mission. In contrast, the leaves denote the 
directives, which are low-level detailed characteristics. 
The internal nodes occupy the middle ground depict- 
ing functionalities at different levels of abstraction. We 
observe that the abstraction level of a node increases 
with its decreasing distance from the root (distance is 
the number of edges in the shortest path). Thus, the 
natural hierarchical structure of the graph indicates 
the granularity of different entities. 

4.3 Scalability 

Current traceability techniques are more suited for tracing 
from and among structured documents of the solution space, 
than within the informality of the problem space. In addi- 
tion, these techniques also have to scale up to maintaining 
traceability in large systems. Our solution approach, the CE 
process, provides inherent traceability information, which 
can be used to adequately manage the enormous complexity 
of large-scale systems, or to serve the interests of small-scale 
system development. In either case, the CE approach facil- 
itates traceability within and between the different spaces. 
In particular, as discussed in Section 13.1.21 CE facilitates 
traceability in the problem space, which has been largely 
neglected hitherto. 

4.4 Human Factors 

Traceability is often viewed as an activity that is extra- 
neous to the actual development process. Human beings 
regard traceability efforts as invasive and time-consuming 
because of the inability to generate automatic traces as a 
by-product of development. In addition, it is difficult to 
trace between artifacts created by different users. However, 
we claim that using a Capabilities-based approach reconciles 
these problems: 

• Integrating Traceability: The FD graph is the basis for 
the decomposition and formulation activities of the CE 
approach. Additionally, its edges behave as links, and 
thereby serve as a means for tracing between needs, 
directives and Capabilities. Thus, unlike current tech- 
niques in the CE development approach there is little 
overhead in producing trace information. 



• Bridging Semantic Differences: As discussed in Sec- 
tion 13.41 the difficulty of tracing artifacts across dif- 
ferent spaces is alleviated by maintaining the linkages 
between spaces. 

4.5 Cost Benefit Analysis 

Complete and comprehensive traceability between every 
entity produced during the development process is theoret- 
ically desirable but practically infeasible. The cost of main- 
taining all possible traces is not commensurate with the ad- 
vantages one may obtain. In particular, as discussed in Sec- 
tion 13.3.21 to derive maximal benefits of traceability it is 
more prudent to maintain links between entities that are 
mission-critical or those that are described at a high-level of 
abstraction. We know that Capabilities enable one to ab- 
stract back from the lower details and focus on larger aspects 
of complex systems. By the same token, the requirements 
associated with Capabilities permit the analysis of details 
pertinent to that function. 

We certainly acknowledge that there is an overhead cost 
associated with CE. We conjecture that this cost is minimal 
when one considers that the inherent traceability provided 
by CE reduces the cost associated with upfront traceability 
effort. Additionally, the cost-savings achieved through the 
property of change-tolerance, the ease of downstream main- 
tainability, and the facility to support critical traceability, 
argue that the the introduction of Capabilities provides ben- 
efits that exceed the costs of traceability. 

5. CONCLUSION 

Empirical evidence suggests that pre-RS traceability is 
crucial for the success of RT. This type of traceability is con- 
cerned with capturing relationships between requirements 
and their sources, which are primarily user needs. How- 
ever, this process is challenged by the vast disparity be- 
tween the informality of a user need and the rigidity of a 
system requirement. We claim there exists an intermedi- 
ary space called the transition space, which can structure 
the movement from one space to the other. More specif- 
ically, we identify highly cohesive, minimally coupled, op- 
timized functional abstractions termed Capabilities in this 
space. Here the Capabilities are associated with a set of 
directives, which are obtained by the decomposition of user 
needs. Hence, directives preserve and carry domain infor- 
mation from the problem to the transition space. However, 
it is the Capabilities that progress unchanged into the solu- 
tion space, where their directives are transformed to require- 
ments. Therefore, although, the spaces are dissimilar they 
are connected through common entities. By establishing 
such relationships, we are no longer constrained by the tra- 
ditional techniques of traceability. The use of directives and 
Capabilities generates an inherent traceability mechanism 
from needs to requirements. Furthermore, the structured 
nature of this approach supports the development of auto- 
mated tools to capture and analyze different trace paths. 
Thus, by the virtue of using a Capabilities-based develop- 
ment approach, the effort to directly relate informal needs 
and formal system requirements is reduced, the complexity 
gap between the spaces is bridged, and the ability to trace 
requirements back to their needs and vice- versa, i. e. pre-RS 
traceability, is provided. 
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